✨ Fiche d'Aide à la Décision
Document interactif — Tout s'ouvre directement dans le navigateur
Document Word Original
Visualisation du document DOCX converti en HTML. Tout le contenu est éditable.
FAD
-
DOCUMENT D’ANALYSE FONCTIONNEL
-
FUNCTIONAL ANALYSIS DOCUMENT
Processus Production
Microsoft Business Central
- ANAL
Sommaire
3. Planification de la fabrication – Produits finis 5
4. Planification de la fabrication – Composants 6
5. Planification – Traiter les messages d'action 1.2 7
6. Gérer les ordres de fabrication 8
8. Enregistrer la consommation 10
9. Enregistrer la production 11
13. Annexe 1 : Liste d‘écarts 14
Ce document liste l’analyse fonctionnel sur les processus métier du client concernant le domaine des achats. Les principaux objectifs de l’analyse fonctionnel sont :
- Visiter les sites clients comme les usines, entrepôts et/ou bureaux
- Conduire des ateliers orientés processus.
- Ne pas rentrer en profondeur sur les fonctionnalités de l’ERP ni faire de démonstrations
- Comprendre la façon de travailler actuelle, les points faibles et les attentes globales et futures
- Identifier les écarts critiques et les interfaces qui peuvent avoir un impact sur le projet
- Identifier les volumes des référentiels et données transactionnelles
- Confirmer le périmètre fonctionnel, technique, géographique et organisationnel du projet
- Identifier un jeu de donnée nécessaire pour l’ERP pour mieux préparer les ateliers de démonstration.
Ce document a été préparé sur la base d‘atelier(s) réalisés avec les membres de l'équipe de projet suivants :
Atelier | Date | Lieu | Almakom | Client |
1er atelier | … | … | Nom et Prénom | Nom et Prénom |
2ème atelier | … | … | Nom et Prénom | Nom et Prénom |
Versions du document
Version | Date | Description | Ecrit par | Approuvé par |
Draft | JJ/MM/AAAA | Draft | Nom et Prénom | Nom et prénom |
… | JJ/MM/AAAA | … | … | … |
Membre de l‘équipe | Fonction | |
Nom et Prénom | … | … |
Nom et Prénom | … | … |
Les processus standards ERP qui font partie des ateliers d’analyse sur les achats sont :
3. Planification de la fabrication – Produits finis
3.1. Contexte et Hypothèses
Décrire la situation actuelle : les équipes conçoivent les pièces dans Catia, extraient les listes de pièces (BOM) sous forme HTML ou Excel, puis les importent manuellement dans un système interne. Chaque pièce possède une fiche « article » où sont renseignées les informations générales et les actions (dates de besoin, numéros de commande). Le suivi des achats s’effectue via un tableau similaire à un « journal des achats », affichant les pièces non commandées (Unvalidated Purchase Order) et les pièces commandées/réceptionnées (Validated Order) avec un code couleur (gris = non commandé, jaune = commandé, vert = reçu). La validation des actions repose sur un « workflow validation » où l’opérateur signe la date d’exécution. La documentation (plans PDF, certificats) n’est pas intégrée ; elle reste stockée dans des dossiers Windows séparés, ce qui entraîne une saisie manuelle supplémentaire.
Identifier les points critiques : saisie manuelle lourde, absence d’attachement de documents PDF, incohérence possible entre l’arborescence 3D (Catia) et l’arborescence de production, traçabilité dépendante de validations manuelles, visibilité limitée aux utilisateurs sans tableau de bord personnalisé.
Lister les attentes client : tableau de bord configurable selon le rôle (gestionnaire d’activité, chef de projet, responsable production), recherche rapide via la petite loupe, automatisation de l’import BOM, intégration des pièces dans la fiche article, possibilité d’attacher directement les PDF aux actions, suivi automatisé des dates et signatures dans le workflow validation, visibilité en temps réel des statuts d’achat et de réception.
Formuler les hypothèses : les utilisateurs disposeront de rôles définis dans BC, le tableau de bord pourra être personnalisé par raccourcis, les données de besoin et les dates de commande seront saisies dans la fiche article, les validations seront effectuées via le workflow intégré, les documents PDF seront stockés dans le système BC et non plus dans des dossiers externes.
Les hypothèses qui peuvent avoir un impact sur le projet doivent être indiquées.
3.2 Schéma des processus ERP : Planification – Calcul du MPS 1.0
3.3. Principales règles de gestion
Définir les règles de gestion du client et les réponses de Business Central
- **Extraire les listes de pièces depuis Catia** → importer la hiérarchie dans la **fiche article** (BOM) ; Business Central crée les nouvelles pièces après recherche d’existence et génère le fichier 3D partagé.
- **Gérer la numérotation projet** → le designer attribue une numérotation « zéro » dans la **fiche article** ; le système accepte des numéros spécifiques par projet.
- **Attribuer des actions à chaque pièce** → dans la partie « General Data » de la **fiche article**, saisir les dates de besoin, le sous‑traitant et le numéro de commande.
- **Valider les actions** → le **workflow validation** enregistre date et signature de la personne (ex. Daniel) pour chaque action, assurant la traçabilité.
- **Traçabilité des pièces multiples** → lorsqu’une même pièce apparaît dans plusieurs sous‑ensembles, Business Central permet la validation groupée des commandes et actions, facilitant le suivi de montage.
- **Créer et valider les commandes** → le chef de projet utilise le **journal des achats** pour créer les ordres d’achat, rechercher par sous‑traitant, cocher les cases et cliquer sur **validation** ; le numéro de commande est alors affecté à chaque article et les lignes passent du tableau « à commander » au tableau « commandées ».
- **Documenter les pièces** → Business Central offre la possibilité d’attacher les PDF (plans, certificats, rapports) directement à la **fiche article** ou aux **actions**, éliminant la gestion manuelle dans les dossiers Windows.
- **Contrôle d’entrée (incoming)** → dès réception physique, l’opérateur lance le **contrôle qualité d’entrée** (niveau simplifié ou poussé) ; le résultat est enregistré dans la **fiche article** et notifie le chef de projet.
- **Gestion des offres** → les appels d’offres restent sous forme de fichiers Excel, importables dans Business Central pour alimenter les besoins (needed) sans intégration directe dans le système.
- **Gestion des certificats** → le chef de projet indique « certificat 3.1 demandé » dans les **actions** ; Business Central suit la présence du certificat et son coût associé.
- **Gestion des pièces standards** → les fournisseurs et numéros d’article sont pré‑configurés ; le chef de projet réserve le numéro de commande, génère éventuellement le document papier, puis valide dans le système.
Ces règles assurent une planification de la fabrication cohérente, une traçabilité complète et une validation automatisée des achats et du contrôle qualité.
3.4. Documents et statistiques
Imprimer le bon de commande papier depuis la **fiche article** lorsqu’un chef de projet réserve un numéro et crée le document Word de commande.
Imprimer la **fiche de validation d’action** contenant la date et la signature de la personne qui a validé la réception, la préparation ou l’envoi des pièces.
Imprimer la **check‑list d’incoming** utilisée par l’opérateur d’atelier pour vérifier le contenu du paquet, cocher les documents présents et saisir le numéro de série fournisseur.
Afficher le **tableau de bord** adapté au rôle (gestionnaire d’activité, chef de projet, responsable production) avec les raccourcis configurés et les indicateurs suivants :
- Nombre de pièces **non commandées** (liste « Unvalidated Purchase Order »)
- Nombre de pièces **commandées et validées** (liste « Validated Order »)
- Statut de chaque pièce : standard, pièce projet, qualité requise, modification planifiée (codification ALM, DES, B01, B02, …)
- Suivi de traçabilité : date de validation, signature, numéro de série fournisseur associé
Générer les **rapports d’état** qui résument :
- Volume des commandes créées par période, par sous‑traitant et par type de standard
- Taux de pièces réceptionnées avec checklist remplie et photos jointes
- Écart entre pièces commandées et pièces effectivement reçues
[INFORMATION MANQUANTE]
Décompter : actuellement ≈ 10 pièces reçues par jour dans le processus d’incoming ; prévision ≈ 100 pièces par jour si le volume augmente, ce qui complexifiera la gestion des check‑lists et du suivi des lignes BOM.
Enregistrer : une documentation de 160 pages liée via SharePoint pour la nomenclature SOLIDWORKS et les versions de lignes BOM ; fréquence de création ou de mise à jour de ce type de document non précisée → **[INFORMATION MANQUANTE]**.
Compter : les lignes d’articles créées automatiquement par l’import BOM et les lignes ajoutées manuellement (ressources, etc.) ; nombre de lignes par période non indiqué → **[INFORMATION MANQUANTE]**.
Suivre : les cases à cocher « créé depuis interface » permettant d’isoler les lignes générées par SOLIDWORKS lors des nouvelles versions ; volume de ces drapeaux par jour/semaine/mois non fourni → **[INFORMATION MANQUANTE]**.
Ainsi, le volume de données observable se limite à ≈ 10 à 100 pièces journalières et à un document de 160 pages stocké sur SharePoint, sans données chiffrées supplémentaires sur le nombre de documents ou d’enregistrements par période.
3.6. Ecarts critiques et interfaces
Identifier les écarts critiques :
- **Absence d’attachement de documents PDF** : le système actuel ne permet pas d’intégrer les plans, rapports ou certificats dans les actions. → Interface : besoin d’un **document management** lié à la **fiche article** et aux **actions** du workflow de validation.
- **Saisie manuelle des dates et signatures** : les dates de besoin et les validations sont renseignées à la main, sans traçabilité automatisée. → Interface : automatiser le **workflow validation** avec horodatage et signature numérique sur la **fiche article** et le **journal des achats**.
- **Pas de champ « lead time »** dans les commandes : aucune date d’approvisionnement n’est enregistrée dans le tableau des pièces. → Interface : ajouter un champ **lead time** sur la **fiche article** et le **journal des achats**.
- **Décalage entre l’arborescence Catia et l’assemblage final** : la structure de conception 3D (Catia) ne correspond pas toujours à la logique d’assemblage, créant des incohérences de suivi. → Interface : développer un import/export de **BOM** (fichier HTML/Excel) depuis Catia vers la **fiche article** et le **tableau de bord** de production.
- **Gestion des pièces standards vs projets** : la codification actuelle (ALM, DES, B01, B02…) n’est pas uniformisée dans BC, risquant des doublons. → Interface : harmoniser la **fiche article** avec les règles de numérotation du projet et du standard.
- **Suivi des statuts couleur (gris, jaune, vert)** : le système actuel utilise des indicateurs couleur non reproduits dans BC. → Interface : créer des champs d’état (Non commandé, Commandé, Réceptionné) dans la **fiche article** et les refléter dans le **tableau de bord**.
- **Documentation hors‑système** : les PDF sont stockés dans des dossiers Windows séparés, sans lien avec BC. → Interface : connecter le **document management** de BC aux dossiers partagés ou migrer les fichiers dans le **document library** de BC.
Ces écarts doivent être inscrits dans la liste des écarts livrée à la fin de la phase d’analyse.
Ces écarts et interfaces doivent être initialisés dans la liste des écarts délivrée qui doit être finie à la fin de la phase d’Analyse.
4. Planification de la fabrication – Composants
4.1. Contexte et Hypothèses
Analyser la situation actuelle : les équipes conçoivent les pièces dans Catia, extraient les nomenclatures sous forme de fichiers HTML ou Excel, puis les importent dans un système interne. Chaque pièce possède une catégorie codifiée (standards qualité, standards modification, projet ALM/DES) et un numéro de projet. L’arborescence reproduit la structure 3D, affichant le statut des pièces (gris = non commandé, jaune = commandé, vert = reçu). Deux tableaux listent les « Unvalidated Purchase Order » et les « Validated Order ».
Points critiques :
- Absence de lead‑time ; les dates de besoin sont saisies manuellement dans les actions de la fiche article.
- Aucun moyen d’attacher les plans PDF, certificats ou rapports dans les actions ; la documentation reste stockée dans des dossiers Windows.
- Saisie manuelle lourde des actions, dates et signatures, source de risques d’erreurs et de perte de traçabilité.
- Décalage entre la hiérarchie de conception (Catia) et l’assemblage réel, entraînant des doublons d’articles dans plusieurs sous‑ensembles.
Attentes client : disposer d’un tableau de bord personnalisable selon le rôle (gestionnaire d’activité, chef de projet), centraliser la traçabilité des actions, intégrer les documents PDF aux fiches article et automatiser la gestion des dates de besoin et des commandes.
Hypothèses impactant le projet :
- Le système BC utilisera la « fiche article » pour centraliser les données générales et les actions (dates, signatures).
- Le « journal des achats » remplacera les tableaux Unvalidated/Validated Order, permettant le suivi automatisé des bons de commande.
- Un « workflow validation » sera configuré pour valider les actions et enregistrer les traces.
- Les utilisateurs adopteront les tableaux de bord personnalisés via les raccourcis et favoris.
- Une interface d’import Catia → BC pourra être développée pour transférer les listes de pièces et leurs arborescences.
[INFORMATION MANQUANTE]
Les hypothèses qui peuvent avoir un impact sur le projet doivent être indiquées.
4.2 Schéma des processus ERP : Planification - Calcul du MRP 1.1
4.3. Principales règles de gestion
Définir les règles de gestion du client et les couvrir avec Business Central :
- **Importer la nomenclature depuis Catia** → créer la **fiche article** avec l’arborescence complète et le récapitulatif des pièces. Le champ *General Data* contient les informations générales et les **actions** (date de besoin, numéro de commande fournisseur).
- **Créer une nouvelle pièce** → vérifier l’existence dans la base, saisir la **fiche article**, générer le fichier 3D et le placer dans les dossiers partagés. Le **workflow validation** des actions trace la date et la signature du responsable (ex. : Daniel).
- **Numérotation projet** → le designer attribue une numérotation à zéro dans la **fiche article** du projet.
- **Gestion groupée des pièces récurrentes** → lorsqu’une même pièce apparaît dans plusieurs sous‑ensembles, le **workflow validation** permet de valider les commandes et les actions en une seule fois, gagnant du temps tout en conservant la traçabilité.
- **Passer les commandes** → le chef de projet utilise le **journal des achats** pour créer les **ordres d’achat**, sélectionner le sous‑traitant, réserver le numéro de commande et saisir les quantités. Le bouton **validation** du **workflow** attribue le numéro de commande à chaque article et déplace les lignes du tableau « à commander » vers le tableau « commandé ».
- **Suivi de la réception** → à l’arrivée du paquet, l’opérateur d’atelier lance le **contrôle d’entrée (incoming)**, enregistre la réception dans le **journal des achats** et valide le **workflow** d’**incoming**. Deux niveaux de contrôle qualité (simplifié ou poussé) sont configurables.
- **Documentation** → les certificats, plans PDF et rapports sont indiqués dans les **actions** (ex. : « certificat 3.1 demandé »), mais ne peuvent pas être joints ; ils restent stockés dans les dossiers Windows, nécessitant une procédure manuelle de référence.
- **Offres** → les appels d’offres restent sous forme de fichiers Excel externes, aucune intégration directe dans la **fiche article**.
Ces règles assurent la cohérence entre la conception 3D, la planification de la fabrication et le suivi des achats, tout en offrant traçabilité, validation centralisée et contrôle qualité conforme aux exigences du client.
4.4. Documents et statistiques
Imprimer le **bon de commande** depuis le **journal des achats** pour chaque pièce usinée ou standard ; imprimer le **rapport de suivi des pièces non commandées** (tableau « Unvalidated Purchase Order ») afin de disposer d’une vue papier des articles à commander ; imprimer le **rapport de pièces validées** (tableau « Validated Order ») pour consigner les articles déjà attribués à une commande ; imprimer le **document de validation** généré par le **workflow validation** (date et signature de la personne ayant validé l’action) afin de garantir la traçabilité ; imprimer le **tableau de bord** personnalisé (raccourcis, favoris) lorsqu’il est utilisé comme support de décision par le gestionnaire d’activité ou le chef de projet.
Statistiques attendues :
- **Nombre d’articles non commandés** (ligne du tableau « Unvalidated Purchase Order »)
- **Nombre d’articles commandés et validés** (ligne du tableau « Validated Order »)
- **Date de validation** et **signature** pour chaque action de validation (extrait du workflow)
- **Quantité commandée vs quantité reçue** pour chaque pièce, incluant les **spares** et les **livraisons partielles**
- **Statut de la documentation** : présence ou absence de PDF (dessins, certificats) associés à chaque article, suivi manuellement dans les dossiers Windows ou via SharePoint
- **Temps moyen entre la création du bon de commande et la réception de la pièce** (calculable à partir des dates d’émission du bon et d’entrée en stock)
Ces impressions et indicateurs permettent aux responsables production, chefs de projet et gestionnaires d’activité de contrôler la planification des composants, d’assurer la traçabilité des validations et de suivre l’avancement des achats et réceptions.
[INFORMATION MANQUANTE]
Indiquer le volume des données référentielles : la **fiche article** crée pour chaque pièce, les lignes de la **BOM** importées depuis SOLIDWORKS, les cases à cocher « créé depuis interface » (flag) et les lignes ajoutées manuellement.
[INFORMATION MANQUANTE]
Indiquer le nombre de documents par période : le processus actuel génère environ **10 pièces** (documents : fiches article, checklist, étiquettes) par jour ; une hausse prévue pourrait porter ce volume à **100 pièces** par jour, ce qui augmenterait proportionnellement le nombre de documents à gérer quotidiennement.
Aucune donnée chiffrée n’est fournie pour les volumes hebdomadaires, mensuels ou annuels, ni pour le nombre de documents liés aux liens SharePoint, aux versions de nomenclature ou aux rapports d’étiquetage.
[INFORMATION MANQUANTE]
4.6. Ecarts critiques et interfaces
Identifier les écarts critiques :
- **Absence d’interface Catia → fiche article** : les listes de pièces sont extraites de Catia (ou 4K) sous forme HTML/Excel, puis saisies manuellement dans le système. Aucun flux automatisé n’alimente la fiche article ni le tableau des nomenclatures.
- **Manque d’import HTML/Excel → liste des pièces** : le processus actuel repose sur le copier‑coller de fichiers HTML ou Excel, sans mécanisme d’import structuré dans Business Central.
- **Pas de champ lead‑time dans le journal des achats** : les dates de besoin sont renseignées uniquement dans les actions de la fiche article, aucune date de livraison n’est associée aux lignes du journal des achats.
- **Impossibilité d’attacher des PDF aux actions** : plans, rapports ou certificats ne peuvent pas être intégrés dans les actions de la fiche article ; la documentation reste stockée dans des dossiers Windows séparés.
- **Validation manuelle des actions → workflow validation** : la traçabilité (date, signature) repose sur une saisie manuelle, sans déclenchement automatique d’un workflow de validation.
- **Décalage entre arborescence de conception et arborescence de production** : la structure Catia (sous‑ensembles rotor, stator, etc.) n’est pas toujours cohérente avec l’arborescence utilisée pour la planification, créant des incohérences lors du transfert des pièces.
- **Gestion manuelle du statut Unvalidated / Validated Order** : le déplacement des lignes entre les deux tableaux du système actuel se fait à la main, sans règle automatisée de mise à jour du statut de la commande.
Identifier les interfaces :
- **Catia ↔ fiche article** : besoin d’un connecteur pour exporter la nomenclature et créer/mettre à jour les fiches article.
- **HTML/Excel ↔ liste des pièces** : mise en place d’un import batch qui alimente la liste des pièces et les champs généraux (numéro projet, catégorie).
- **Dossier partagé ↔ document management** : interface permettant d’attacher directement les PDF aux actions de la fiche article.
- **Journal des achats ↔ workflow validation** : déclenchement d’un workflow dès que la date de besoin ou la signature est saisie.
- **Arborescence de conception ↔ planification de fabrication** : alignement des sous‑ensembles entre le modèle 3D et la structure de production dans Business Central.
Ces écarts et interfaces seront consignés dans la liste d’écarts finale à l’issue de la phase d’analyse.
Ces écarts et interfaces doivent être initialisés dans la liste des écarts délivrée qui doit être finie à la fin de la phase d’Analyse.
5. Planification – Traiter les messages d’action 1.2
Décrire la situation actuelle : les équipes conçoivent les pièces dans Catia, extraient les listes de pièces sous forme de fichiers HTML ou Excel, puis les importent dans le système interne. Chaque projet possède une arborescence qui indique le statut des pièces : gris = non commandé, jaune = commandé, vert = réceptionné. Deux tableaux affichent les « Unvalidated Purchase Order » (pièces non commandées) et les « Validated Order » (pièces commandées et réceptionnées). Dans la fiche de chaque article, les utilisateurs renseignent les dates de besoin, les numéros de commande et valident les actions avec signature, assurant ainsi la traçabilité. Les actions sont saisies manuellement ; aucune pièce jointe PDF (plans, certificats) ne peut être intégrée, les documents restent stockés dans des dossiers Windows séparés.
Identifier les points critiques : saisie manuelle fastidieuse, absence d’attachement de documents PDF dans les actions, risque d’incohérence entre la structure 3D (Catia) et l’arborescence du système, impossibilité de définir des lead‑time directement dans les commandes, dépendance à des dossiers partagés pour la documentation.
Lister les attentes client : automatiser la création et la mise à jour des fiches article, intégrer les documents PDF aux actions, disposer d’un suivi des délais d’approvisionnement, harmoniser l’arborescence du système avec la conception 3D, centraliser la traçabilité dans un seul environnement.
Formuler les hypothèses impactant le projet : [INFORMATION MANQUANTE].
Les hypothèses qui peuvent avoir un impact sur le projet doivent être indiquées.
5.2 Planification –Traiter les messages d’action 1.2
5.3. Principales règles de gestion
Définir les règles de gestion principales et les réponses de Business Central :
- **Extraire les listes de pièces depuis Catia** → importer l’arborescence dans la **fiche article** (General Data) ; chaque pièce possède son numéro, son sous‑ensemble et son groupe de validation.
- **Créer une nouvelle pièce** uniquement après recherche dans la base : le processus de création dans la **fiche article** inclut une vérification d’existence, puis la génération du fichier 3D et le partage via dossiers Windows.
- **Numérotation projet** : le designer du projet initialise la séquence à zéro dans la **fiche article** dédiée au projet.
- **Attribuer des dates de besoin et des numéros de commande** dans les **actions** de la fiche article ; le chef de projet saisit le numéro de commande fournisseur et le relie à l’action.
- **Valider les actions** avec signature : le **workflow validation** enregistre la date et le signataire, assurant traçabilité complète (réception, préparation, envoi au traitement).
- **Gérer la documentation** : les rapports, numéros de rapport et certificats sont saisis manuellement ; aucune inclusion de PDF dans les actions n’est possible actuellement → **[INFORMATION MANQUANTE]** sur la prise en charge native des PDF.
- **Regrouper les validations** : lorsqu’une même pièce apparaît dans plusieurs sous‑ensembles, le **workflow validation** permet de valider les commandes et actions groupées, réduisant le temps de saisie.
- **Suivre la traçabilité** : chaque validation lie la pièce à son sous‑ensemble, permettant de retrouver rapidement où la pièce a été montée.
- **Créer et valider les achats** : le chef de projet utilise le **journal des achats** pour réserver un numéro, remplir le papier de commande (copie manuelle des références) puis, via le bouton de **validation**, attribue les quantités et fait passer les pièces du tableau « à commander » au tableau « commandées ».
- **Contrôle d’entrée (incoming)** : à la réception, l’opérateur d’atelier effectue l’**incoming** et déclenche le **contrôle qualité** (niveau simplifié ou poussé). Le statut « reçue » ne passe à « validée » qu’après validation du contrôle.
- **Communiquer les exigences** : le chef de projet indique dans les **actions** les certificats requis (ex. « certificat 3.1 demandé ») et les commentaires de prix.
Ces règles, implémentées via les objets BC cités, assurent cohérence entre conception 3D, gestion des achats, traçabilité et contrôle qualité.
5.4. Documents et statistiques
Imprimer la **commande papier** générée lors de la validation d’une pièce ; imprimer le **PDF du dessin** ou du **certificat** associé à la pièce ; imprimer la **check‑list d’incoming** remplie par l’opérateur d’atelier.
Afficher les **tableaux** :
- Tableau « Pièces non commandées » (Unvalidated Purchase Order) : indique le nombre de fiches article encore sans commande.
- Tableau « Commandes validées » (Validated Order) : indique le nombre de fiches article dont la commande a été enregistrée et déplacées du tableau supérieur vers le tableau inférieur.
Collecter les **statistiques de suivi** :
- Total pièces à commander vs total pièces commandées.
- Nombre de pièces réceptionnées, nombre de spares et quantité commandée par sous‑traitant.
- Dates de validation et signatures des utilisateurs (traçabilité des actions).
Suivre les **états métiers** :
- État « Unvalidated » tant que la pièce n’est pas associée à une commande.
- État « Validated » dès que la validation de l’action (date + signature) est enregistrée.
- État « Incoming » après que l’opérateur a complété la checklist et éventuellement renseigné le numéro de série fournisseur.
[INFORMATION MANQUANTE] – objets BC spécifiques tels que « fiche article », « journal des achats » ou « workflow validation » ne sont pas explicitement cités dans les notes sources.
Indiquer les volumes des données référentielles et le nombre de documents :
- **Fiche article** : création d’une fiche article pour chaque pièce importée depuis SOLIDWORKS ou saisie manuelle. Le système génère automatiquement les articles de la nomenclature (BOM) et conserve les lignes manuelles (ressources, etc.) inchangées.
- **Lignes de vente** : chaque ligne de vente référence un ou plusieurs articles rattachés à un même projet.
**Volumes de pièces reçues** :
- Actuellement : ≈ 10 pièces / jour.
- Projection : ≈ 100 pièces / jour (scénario de croissance).
**Documents liés** :
- Un document de 160 pages est référencé via un lien SharePoint (pas de téléchargement).
- Aucun volume chiffré fourni pour le nombre de documents quotidiens, hebdomadaires, mensuels ou annuels. → **[INFORMATION MANQUANTE]**.
**Données référentielles** :
- Flag « créé depuis interface » indique les lignes importées de SOLIDWORKS.
- Aucun chiffre indiqué pour le nombre total de fiches article, de lignes de BOM ou de flags actifs. → **[INFORMATION MANQUANTE]**.
En résumé, le processus gère : ~10 pièces / jour (potentiellement 100 / jour), un document de 160 pages référencé, et des fiches article générées automatiquement à partir de la BOM. Toutes les autres métriques de volume restent non spécifiées.
5.6. Ecarts critiques et interfaces
Identifier les écarts critiques :
- **Absence d’attachement de documents PDF** : le système actuel ne permet pas d’intégrer les plans, rapports ou certificats dans les actions de la fiche article. → Interface : besoin d’un lien « pièce jointe » vers le champ *Document* de la fiche article (BC).
- **Gestion manuelle des dates et signatures** : les dates de besoin et les validations sont saisies à la main dans les actions, sans automatisation ni traçabilité centralisée. → Interface : mise en place d’un *workflow validation* lié au journal des achats pour automatiser la validation et enregistrer la signature.
- **Manque de lead‑time / délais d’approvisionnement** : aucune date prévisionnelle n’est renseignée dans le système actuel, uniquement des dates d’action ponctuelles. → Interface : ajout du champ *Lead‑time* dans la fiche article et synchronisation avec le *journal des achats*.
- **Incohérence entre l’arborescence Catia et l’assemblage réel** : la hiérarchie 3D ne reflète pas toujours la logique d’assemblage, créant des doublons et des difficultés de suivi. → Interface : création d’une table de correspondance « Arborescence » entre les numéros de projet (ex. ALM, DES) et les groupes d’articles BC.
- **Duplication de pièces standards** : le processus de recherche de pièces existantes repose sur une vérification manuelle dans des dossiers partagés, entraînant des risques de doublons. → Interface : implémentation d’un *lookup* automatisé sur la fiche article pour vérifier l’existence d’un numéro standard avant création.
- **Export limité (HTML/Excel) sans intégration ERP** : les listes de pièces sont exportées hors BC, puis re‑saisies, augmentant les erreurs de saisie. → Interface : import automatisé des fichiers HTML/Excel vers la fiche article via un *data exchange*.
- **Gestion des statuts couleur (gris, jaune, vert) non standardisée** : les indicateurs visuels ne sont pas mappés aux états du système BC. → Interface : mapping des statuts couleur aux champs *Statut* du journal des achats et du workflow de validation.
Ces écarts doivent être consignés dans la liste des écarts livrée et finalisés avant la clôture de la phase d’Analyse.
Ces écarts et interfaces doivent être initialisés dans la liste des écarts délivrée qui doit être finie à la fin de la phase d’Analyse.
6. Gérer les ordres de fabrication
Décrire la situation actuelle : les équipes conçoivent les pièces dans Catia, extraient les listes de pièces sous forme HTML ou Excel, puis les importent dans le système interne. Elles utilisent une arborescence qui reproduit la structure 3D ; chaque pièce possède un statut couleur (gris = non commandée, jaune = commandée, vert = réceptionnée). Deux tableaux affichent les « Unvalidated Purchase Order » et les « Validated Order ». Dans la fiche article, le champ **General Data** permet de saisir des dates de besoin et des numéros de commande ; les actions associées sont validées manuellement avec date et signature, fonctionnant comme un workflow validation. Les utilisateurs remplissent à la main les informations et stockent les documents PDF (plans, certificats) dans des dossiers Windows, car le système ne supporte pas l’attachement de fichiers aux actions.
Points critiques :
- Absence d’intégration documentaire : impossibilité d’ajouter les PDF directement dans les actions.
- Saisie manuelle lourde : risque d’erreurs et perte de temps.
- Gestion de la traçabilité dépendante de la validation manuelle des actions.
- Arborescence parfois incohérente avec l’assemblage final, entraînant des doublons de pièces à valider séparément.
Attentes client :
- Centraliser la nomenclature et les pièces dans la fiche article de Business Central.
- Automatiser la création et le suivi des ordres de fabrication via le journal des achats et le workflow validation.
- Permettre l’attachement de documents PDF aux actions ou à la fiche article.
- Uniformiser la codification des pièces (standards, projets) et synchroniser les statuts couleur avec les états du système.
Hypothèses impactant le projet :
- Le client pourra exporter les listes de pièces depuis Catia au format Excel compatible avec l’import BC.
- Les catégories de pièces (standards, projets) seront conservées telles quelles dans les champs de la fiche article.
- Le workflow validation existant pourra être reproduit dans Business Central sans modification majeure.
- Les utilisateurs disposeront d’un accès aux dossiers Windows pour la gestion documentaire externe.
- Aucun lead‑time ou date d’approvisionnement n’est actuellement renseigné ; il devra être ajouté dans le champ **General Data** de la fiche article.
Les hypothèses qui peuvent avoir un impact sur le projet doivent être indiquées.
6.2. Schéma des processus ERP : Gérer les ordres de fabrication 2.0
6.3. Principales règles de gestion
Importer la liste de pièces depuis Catia : le système doit reproduire l’arborescence et le récapitulatif des pièces dans la **fiche article** afin de garantir la cohérence entre le modèle 3D et l’assemblage final.
Créer les nouvelles pièces : avant toute création, rechercher l’existence dans la base ; si absent, saisir le **General Data** de la fiche article, ajouter le fichier 3D et le partager dans les dossiers Windows.
Attribuer à chaque article des **actions** : définir la date de besoin, le sous‑traitant, le numéro de commande et les quantités.
Valider les actions : le responsable (ex. Daniel) signe la validation, ce qui trace la date et la signature dans la fiche article et assure la traçabilité de chaque pièce, même lorsqu’elle apparaît dans plusieurs sous‑ensembles.
Grouper les validations : si une même pièce figure dans plusieurs sous‑ensembles, valider les commandes et les actions en une seule opération pour gagner du temps.
Réserver un numéro d’achat et valider la commande : via le **journal des achats**, le chef de projet recherche par sous‑traitant, coche les cases, saisit les quantités et utilise le **workflow validation** pour marquer la pièce comme « achetée ». La validation déplace les lignes du tableau supérieur vers le tableau inférieur, indiquant que la commande est enregistrée.
Documenter les exigences : dans les actions, préciser les certificats requis (ex. certificat 3.1) et les commentaires de prix. Les PDF (plans, rapports, certificats) ne peuvent pas être joints ; ils restent stockés dans les dossiers partagés, ce qui constitue une limitation actuelle.
Gérer l’incoming : à la réception physique, l’opérateur d’atelier effectue l’**incoming** (contrôle d’entrée). Deux niveaux de **contrôle qualité** – simplifié ou poussé – valident que la pièce reçue correspond aux exigences avant d’être mise à disposition du projet.
Informer le chef de projet : dès que l’incoming est validé, le responsable notifie le chef de projet de la disponibilité de la pièce.
[INFORMATION MANQUANTE] (intégration automatique des PDF dans les actions).
6.4. Documents et statistiques
Imprimer la **commande papier** générée par le chef de projet lorsqu’il crée son document Word de commande ; imprimer le **rapport de validation** contenant la date et la signature de la personne qui a validé chaque action.
Afficher les **tableaux de suivi** :
- Tableau « Unvalidated Purchase Order » : liste les pièces non commandées.
- Tableau « Validated Order » : liste les pièces dont la commande est validée et déplacées du tableau supérieur.
Collecter les **statistiques métiers** :
- Nombre de pièces non commandées (extrait du tableau Unvalidated).
- Nombre de pièces validées (extrait du tableau Validated).
- Taux de validation : (Validées / Total pièces) × 100 %.
- Historique des validations : date, signature et utilisateur pour chaque action.
- Suivi des réceptions : indicateur de réception (paquet reçu, photos prises, checklist remplie) et éventuel numéro de série fournisseur associé.
Fournir le **tableau de bord** personnalisable selon le rôle (gestionnaire d’activité, chef de projet, production) : raccourcis, indicateurs clés et accès rapide aux listes, rapports et favoris.
[INFORMATION MANQUANTE] – Détails des états spécifiques de l’ordre de fabrication (ex. : état « En cours », « Terminé », etc.) et des rapports de production standardisés.
Décrire les volumes de données référentielles et le nombre de documents associés aux ordres de fabrication
- **Fiche article** : réception actuelle de **10 pièces par jour** ; prévision d’augmentation à **100 pièces par jour** lorsqu’un volume plus important sera traité.
- **BOM (nomenclature)** : importation automatisée depuis SOLIDWORKS ; chaque import crée automatiquement les articles et leurs lignes dans le système, incluant un indicateur « créé depuis interface » pour distinguer les lignes générées automatiquement des lignes saisies manuellement. Aucun chiffre exact fourni sur le nombre d’articles ou de lignes créés.
- **Étiquettes** : génération automatique d’étiquettes pour chaque pièce, incluant le projet, le numéro de série et le lien vers le document SharePoint. Aucun volume chiffré indiqué.
- **Documents liés (ex. plans, spécifications)** : les fichiers volumineux (ex. 160 pages) ne sont pas stockés dans Business Central mais référencés via un lien SharePoint. Le nombre de documents créés ou liés par jour, semaine, mois ou année n’est pas précisé. → **[INFORMATION MANQUANTE]**
En résumé, le seul volume chiffré disponible concerne les pièces reçues : **10 pièces/jour** aujourd’hui, avec une perspective de **100 pièces/jour**. Les volumes exacts des références (articles, lignes BOM) et le nombre de documents par période restent non spécifiés dans les notes. → **[INFORMATION MANQUANTE]**.
6.6. Ecarts critiques et interfaces
Identifier les écarts critiques :
- **Absence d’attachement de documents PDF** dans la fiche article ; les plans, rapports et certificats restent stockés dans des dossiers Windows séparés.
- **Manque de champs « lead time »** dans le journal des achats ; aucune date d’approvisionnement n’est renseignée lors de la création d’un ordre d’achat.
- **Saisie manuelle des besoins et des dates** dans les actions de la fiche article ; aucune automatisation du transfert des dates de besoin depuis le logiciel de conception.
- **Non‑intégration du logiciel de CAO (Catia)** : les listes de pièces sont exportées en HTML/Excel puis importées manuellement, sans interface directe vers Business Central.
- **Incohérence entre l’arborescence CAO et l’arborescence de production** ; la logique de sous‑ensembles 3D ne correspond pas toujours à la séquence d’assemblage, créant des divergences de suivi.
- **Gestion séparée des tableaux de bord** ; chaque utilisateur configure ses raccourcis, mais aucune standardisation n’est prévue dans le système.
Définir les interfaces nécessaires :
- **Interface Catia ↔ fiche article** : automatiser l’import du BOM (HTML/Excel) vers la fiche article et le tableau de bord des pièces.
- **Interface dossier partagé ↔ fiche article** : permettre l’attachement direct de PDF (plans, certificats) dans la fiche article.
- **Interface journal des achats ↔ actions de la fiche article** : transmettre les dates de besoin et les numéros de commande depuis les actions vers le journal des achats.
- **Interface workflow validation ↔ actions de la fiche article** : enregistrer automatiquement la date et la signature du validateur lors de la validation des actions.
- **Interface tableau de bord ↔ rôles utilisateurs** : synchroniser les raccourcis et les vues personnalisées avec les paramètres de rôle dans Business Central.
Ces écarts et interfaces doivent être consignés dans la liste des écarts délivrée à la fin de la phase d’analyse fonctionnelle.
Ces écarts et interfaces doivent être initialisés dans la liste des écarts délivrée qui doit être finie à la fin de la phase d’Analyse (après la phase d'Analyse fonctionnel).
Décrire la situation actuelle : les concepteurs utilisent Catia pour créer les modèles 3D et extraient les listes de pièces au format HTML ou Excel. Ces listes alimentent un système interne où chaque pièce apparaît dans une arborescence reproduisant la structure du modèle ; le statut de chaque pièce (non commandée = gris, commandée = jaune, reçue = vert) s’affiche dans deux tableaux « Unvalidated Purchase Order » et « Validated Order ». Les informations générales de chaque pièce sont saisies dans la **fiche article** (General Data) et les actions associées permettent de renseigner une date de besoin, le numéro de commande et de valider l’action avec date et signature (workflow validation). La traçabilité repose sur la validation manuelle des actions. La documentation (plans, certificats PDF) n’est pas intégrée ; elle reste stockée dans des dossiers Windows séparés et doit être saisie manuellement.
Identifier les points critiques : absence de champ dédié aux lead‑time ; impossibilité d’attacher directement les documents PDF aux actions ; saisie manuelle lourde et risque d’erreurs ; arborescence parfois incohérente avec l’assemblage final, entraînant des duplications de pièces dans plusieurs sous‑ensembles.
Lister les attentes client : [INFORMATION MANQUANTE].
Formuler les hypothèses impactant le projet :
- Les listes de pièces seront importées dans Business Central via les fichiers HTML/Excel existants.
- Les catégories de pièces (standards, projets) seront mappées sur les groupes de la **fiche article**.
- Les dates de besoin et numéros de commande seront renseignés dans les champs « Date de besoin » et « Numéro de commande » de la **fiche article** ou du **journal des achats**.
- Le workflow de validation existant pourra être reproduit avec le **workflow validation** de BC.
- Les documents PDF pourront être associés aux pièces grâce à un champ pièce joint ou à la fonction de pièces jointes de BC.
- Les lead‑time seront ajoutés comme nouveaux champs dans la **fiche article**.
Ces hypothèses supposent que les utilisateurs accepteront de remplacer les raccourcis et dossiers Windows par les fonctionnalités natives de Business Central.
Les hypothèses qui peuvent avoir un impact sur le projet doivent être indiquées.
7.2. Schéma des processus ERP : Planifier la production 3.0
7.3. rincipales règles de gestion
Décrire les principales règles du client et comment l’ERP peut y répondre.
7.4. Documents et statistiques
Imprimer le bon de commande papier généré lors de la validation d’une commande d’article (création manuelle du fichier Word, remplissage des numéros d’article et du sous‑traitant, puis impression pour envoi au sous‑traitant).
Imprimer le rapport d’état des pièces non commandées (« Unvalidated Purchase Order ») affiché dans le tableau supérieur du suivi des pièces.
Imprimer le rapport d’état des pièces commandées (« Validated Order ») affiché dans le tableau inférieur du suivi des pièces.
Imprimer le tableau de bord personnalisé (Excel) contenant les indicateurs de suivi de production : nombre de pièces à commander, nombre de pièces reçues, statut de validation, dates et signatures des validations, numéros de série fournisseurs, et répartition par catégorie (standard, projet, etc.).
Statistiques attendues :
- Total de pièces non commandées (colonne du tableau « Unvalidated Purchase Order »).
- Total de pièces validées et déplacées vers le tableau « Validated Order ».
- Nombre de validations effectuées, avec date et signature de chaque valideur.
- Répartition des pièces par catégorie de codification (ALM, DES, B01, B02, …).
- Nombre de pièces commandées par sous‑traitant et numéro d’achat réservé.
- Suivi des pièces reçues : état vert, actions validées, éventuels numéros de série associés.
[INFORMATION MANQUANTE] – Nom exact des objets Business Central (ex. fiche article, journal des achats, workflow validation) utilisés pour ces impressions.
Décrire les volumes de données pour le processus **Planifier la production**
- **Données référentielles** :
- Fiche article : chaque article créé (ex. projet) apparaît dans les lignes de vente et dans la nomenclature (BOM) importée depuis SOLIDWORKS. Aucun volume chiffré n’est indiqué dans les notes. → **[INFORMATION MANQUANTE]**
- Nomenclature (BOM) : importée automatiquement, crée les articles associés. Aucun nombre d’articles ou de versions n’est précisé. → **[INFORMATION MANQUANTE]**
- Flags de création : case à cocher « créé depuis interface » pour identifier les lignes générées par SOLIDWORKS. Aucun total indiqué. → **[INFORMATION MANQUANTE]**
- **Documents entrants (par période)** :
- Réception quotidienne : environ **10 pièces** (documents) par jour ; prévision d’une hausse possible à **100 pièces** par jour, ce qui complexifiera la gestion.
- Checklist : chaque document entrant doit être validé via une checklist remplie dans le système.
- Lien SharePoint : documents volumineux (ex. fichier de **160 pages**) sont référencés par un lien plutôt que téléchargés, comptés comme **1 document** lorsqu’ils sont associés à un projet.
- **Fréquence de mise à jour** :
- Les lignes de la BOM peuvent être modifiées manuellement ou ré‑importées depuis SOLIDWORKS, entraînant la création de nouvelles versions sans toucher aux lignes manuelles (ressources, etc.).
En l’absence de chiffres détaillés sur le nombre total d’articles, de projets ou de versions de nomenclature, les informations chiffrées disponibles se limitent aux flux documentaires décrits ci‑dessus.
7.6. Ecarts critiques et interfaces
Identifier les écarts critiques :
- Absence de champ « lead‑time » dans la **fiche article** ; les dates de besoin sont saisies uniquement dans les actions du système actuel, sans planification automatisée.
- Impossibilité d’attacher des documents PDF (plans, certificats, rapports) aux actions ; la traçabilité repose sur des dossiers Windows séparés.
- Saisie manuelle des numéros de commande et des dates de validation dans les actions ; aucun **journal des achats** automatisé ne capture ces informations.
- Absence de **workflow validation** intégré ; les signatures sont enregistrées manuellement, sans contrôle de conformité dans Business Central.
Déterminer les interfaces nécessaires :
- Interface de transfert de nomenclatures depuis le logiciel 3D (Catia) vers la **fiche article** et le **BOM** de Business Central, incluant les catégories de pièces (standards, projet).
- Interface d’import Excel/HTML vers la **fiche article** pour charger les listes de pièces exportées du logiciel de conception.
- Interface de synchronisation entre le système de gestion de documents Windows et Business Central afin de lier les PDF aux actions de la **fiche article**.
- Interface de mise à jour du **journal des achats** depuis les actions validées, afin d’automatiser le suivi des commandes (Unvalidated → Validated).
Consigner ces écarts et interfaces dans la liste d’écarts livrée, à finaliser à la clôture de la phase d’Analyse fonctionnelle.
Ces écarts et interfaces doivent être initialisés dans la liste des écarts délivrée qui doit être finie à la fin de la phase d’Analyse (après la phase d'Analyse fonctionnel).
8. Enregistrer la consommation
Décrire la situation actuelle : les équipes extraient les listes de pièces depuis Catia, les exportent en HTML ou Excel, puis les importent dans le système interne où chaque pièce apparaît dans une arborescence par projet. Les statuts sont indiqués par couleur (gris = non commandé, jaune = commandé, vert = reçu). Deux tableaux affichent les pièces non commandées (« Unvalidated Purchase Order ») et les pièces validées (« Validated Order »). Les utilisateurs saisissent manuellement les dates de besoin, les numéros de commande et valident les actions avec signature, assurant la traçabilité. Aucun document PDF (plans, certificats) ne peut être joint aux actions ; ils sont stockés séparément sur des dossiers Windows.
Identifier les points critiques : saisie manuelle intensive, absence d’intégration de documents PDF, risque d’incohérence entre l’arborescence 3D et l’arborescence du système, visibilité limitée sur les délais d’approvisionnement (pas de lead‑time automatisé), dépendance à la recherche manuelle de pièces déjà présentes dans le référentiel.
Répondre aux attentes client : automatiser l’enregistrement de la consommation des pièces, réduire la saisie manuelle, permettre l’attachement de documents PDF aux actions, disposer d’un suivi des dates de besoin et des signatures dans un journal dédié, harmoniser l’arborescence du système avec la structure de conception 3D, intégrer les lead‑time pour planifier les achats.
Formuler les hypothèses impactant le projet : les listes de pièces resteront exportées en HTML ou Excel ; les utilisateurs continueront d’utiliser les mêmes rôles (gestionnaire d’activité, chef de projet) avec des tableaux de bord personnalisés ; le système actuel ne supporte pas les pièces en double, donc la logique de codification existante devra être conservée ; les documents PDF resteront stockés sur des partages Windows tant que l’intégration n’est pas développée.
Les hypothèses qui peuvent avoir un impact sur le projet doivent être indiquées.
8.2. Schéma des processus ERP : Enregistrer la consommation 4.0
8.3. Principales règles de gestion
Enregistrer la consommation :
- Vérifier dans la **fiche article** l’existence de la pièce ; si elle n’existe pas, créer la nouvelle pièce après recherche dans la base, puis associer le fichier 3D partagé.
- Saisir dans les **actions** de la fiche article la date de besoin et le numéro de commande attribué (ex. commande chez l’usineur).
- Valider chaque action via le **workflow validation** ; le système trace la date et la signature du valideur, assurant la traçabilité de la réception, de la préparation et de l’envoi au traitement.
- Lors de la réception physique, l’opérateur d’atelier lance l’**incoming** : enregistrer le paquet reçu, affecter le **journal des achats** à la pièce, puis déclencher le contrôle d’entrée (qualité simplifiée ou poussée).
- Communiquer immédiatement au chef de projet la réception ; le contrôle qualité confirme que la pièce correspond aux exigences avant d’être consommée.
- Utiliser la fonction de validation groupée pour les pièces identiques présentes dans plusieurs sous‑ensembles, afin d’attribuer la même commande à toutes les occurrences et de gagner du temps.
- Conserver les documents PDF (plans, certificats, rapports) hors du système ; les numéros de rapport sont remplis manuellement dans les actions, la documentation reste dans les dossiers Windows partagés.
- Après validation, le statut de la pièce passe du tableau supérieur au tableau inférieur, indiquant que la pièce est « achetée » et prête à être consommée dans le projet.
[INFORMATION MANQUANTE] concernant les paramètres spécifiques du module de consommation dans Business Central.
8.4. Documents et statistiques
Imprimer : [INFORMATION MANQUANTE]
Statistiques attendues : [INFORMATION MANQUANTE]
Indiquer les volumes des données référentielles : la **fiche article** créée dans le système apparaît dans les lignes de vente et permet de tracer chaque pièce, sous‑ensemble et projet associé. Le processus d’enregistrement de la consommation utilise ces articles ainsi que les lignes importées depuis SOLIDWORKS (flag « créé depuis interface ») et les lignes saisies manuellement (ressources, heures, planning).
Indiquer le nombre de documents par période : les équipes reçoivent aujourd’hui environ **10 pièces par jour** ; une hausse prévue à **100 pièces par jour** compliquerait la gestion et nécessiterait un suivi structuré. Aucun chiffre n’est fourni pour le nombre de documents (check‑list, étiquettes, liens SharePoint) sur une base jour, semaine, mois ou année.
Indiquer les volumes de documents liés : chaque projet comporte un fichier de **160 pages** stocké sur SharePoint, référencé par lien plutôt que téléchargé.
[INFORMATION MANQUANTE] – Volume exact des données référentielles (nombre d’articles, de lignes BOM, de ressources) et fréquence précise des documents (check‑list, étiquettes) par jour, semaine, mois ou année.
8.6. Ecarts critiques et interfaces
Identifier les écarts critiques :
- **Absence de pièce jointe PDF** : le système actuel ne permet pas d’attacher les plans, rapports ou certificats PDF aux actions d’une fiche article. → besoin d’une interface « document » vers le **journal des achats** ou le **workflow validation** pour stocker les PDF dans Business Central.
- **Saisie manuelle exhaustive** : toutes les informations (dates de besoin, numéros de commande, signatures) sont renseignées à la main dans les actions. → exigence d’un **workflow validation** automatisé et d’une intégration directe depuis le **logiciel 3D (Catia)** vers la **fiche article** afin de pré‑remplir les champs.
- **Gestion documentaire hors système** : les PDF sont conservés dans des dossiers Windows séparés, sans lien avec les enregistrements BC. → besoin d’une interface de synchronisation entre le répertoire partagé et le **journal des achats**/**fiche article**.
- **Pas de champ lead‑time** : le système actuel ne propose pas de date d’approvisionnement dans les commandes, uniquement des dates de besoin dans les actions. → ajouter un champ « lead‑time » dans la **fiche article** et le **journal des achats**.
- **Arborescence non alignée avec l’assemblage** : l’arborescence reproduite depuis Catia ne reflète pas toujours la logique d’assemblage, créant des incohérences de suivi de consommation. → définir une interface de mapping entre la structure Catia et la hiérarchie de **fiche article**/**liste de pièces** dans BC.
- **Statuts couleur non exploités** : les statuts (gris, jaune, vert) indiquant le statut de commande ne sont pas repris dans Business Central. → implémenter un champ de statut dans la **fiche article** synchronisé avec le **journal des achats**.
- **Numérotation projet vs standard** : les catégories de pièces (ALM, DES, B01, B02…) sont codifiées dans le système actuel mais non mappées dans BC. → créer une interface de conversion des codes projet/standard vers les **groupes d’articles** de Business Central.
Ces écarts doivent être consignés dans la liste d’écarts livrée à la fin de la phase d’analyse.
Ces écarts et interfaces doivent être initialisés dans la liste des écarts délivrée qui doit être finie à la fin de la phase d’Analyse.
Décrire la situation actuelle : les utilisateurs extraient les listes de pièces depuis Catia, obtiennent des fichiers HTML ou Excel, puis les importent dans le système interne où chaque pièce apparaît dans une arborescence par projet. Le statut des pièces s’affiche par couleur : gris = non commandé, jaune = commandé, vert = reçu. Deux tableaux affichent les pièces non commandées (Unvalidated Purchase Order) et les pièces commandées validées (Validated Order). Dans la fiche de chaque article (onglet General Data) les utilisateurs renseignent des actions avec dates de besoin, numéros de commande et signent la validation. La traçabilité repose sur ces validations manuelles. Le système ne permet pas d’attacher de documents PDF (plans, certificats) aux actions ; la documentation reste stockée dans des dossiers Windows séparés. Les lead times ne sont pas renseignés dans le système actuel.
Identifier les points critiques : saisie manuelle lourde, absence d’attachement de documents, impossibilité de gérer les dates d’approvisionnement, dépendance à des dossiers externes, risque d’incohérence entre l’arborescence 3D et l’arborescence du système, besoin de validation et de signature pour chaque action.
Recueillir les attentes client : automatiser l’enregistrement de la production, centraliser les pièces, les actions et les documents dans un même environnement, réduire la saisie manuelle, disposer de lead times et de dates d’approvisionnement, garantir la traçabilité avec signatures électroniques, aligner l’arborescence du système avec la structure 3D.
Formuler les hypothèses impactant le projet : les listes de pièces seront toujours exportées au format HTML ou Excel, les catégories de pièces (standards, projets) resteront codifiées comme décrites, les utilisateurs disposeront d’un rôle de gestionnaire d’activité avec tableau de bord personnalisable, les pièces pourront être créées de zéro ou normalisées selon le type, aucune contrainte réglementaire supplémentaire n’est mentionnée.
Les hypothèses qui peuvent avoir un impact sur le projet doivent être indiquées.
9.2. Schéma des processus ERP : Enregistrer la production 5.0
9.3. Principales règles de gestion
Gérer la traçabilité des pièces depuis la conception : la **fiche article** reprend l’arborescence exportée de Catia, regroupe toutes les pièces et sous‑ensembles, et indique le **numéro de pièce** ainsi que le **numéro de sous‑ensemble**.
Attribuer les besoins : dans la **fiche article**, le champ **General Data** permet de saisir les dates de besoin et les références d’ordres d’achat (usineur, sous‑traitant).
Valider les actions : le **workflow validation** enregistre la date et la signature de chaque intervenant (ex. : Daniel qui réceptionne, prépare, envoie la pièce). Cette validation assure le suivi de chaque étape et la traçabilité.
Créer et réserver les commandes : le **journal des achats** sert à réserver un numéro d’achat, à saisir les quantités et à valider la commande. La fonction de validation groupée permet de valider plusieurs pièces d’un coup, ce qui correspond à la pratique du chef de projet qui coche les cases puis valide la commande.
Contrôler la réception : le processus **incoming** consigne la réception physique du paquet, le transfert à l’opérateur d’atelier, puis le **contrôle qualité** (niveau simplifié ou poussé). Le résultat du contrôle (accepté ou non) est enregistré dans la **fiche article** et notifié au chef de projet.
Intégrer les exigences documentaires : les actions de la **fiche article** peuvent contenir des commentaires « certificat 3.1 demandé », garantissant que les certificats ou plans requis sont pris en compte lors de la commande.
Assurer la cohérence entre conception 3D et assemblage : le client veille à ce que les modèles numériques respectent la logique d’assemblage (ex. : rotor, stator séparés) ; la **fiche article** reflète cette logique, facilitant la validation groupée des pièces identiques présentes dans plusieurs sous‑ensembles.
[INFORMATION MANQUANTE] – Détails sur la saisie automatique des documents PDF dans la **fiche article** ou le **journal des achats**.
9.4. Documents et statistiques
Imprimer le bon de commande généré dans le système (numéro d’article, sous‑traitant, numéro de série le cas échéant) pour chaque pièce usinée.
Imprimer le PDF du dessin ou du certificat associé, même si le système ne les intègre pas directement, afin de les joindre au bon de commande.
Imprimer la checklist d’incoming remplie par l’opérateur d’atelier lors de la réception des pièces.
Afficher sur le tableau de bord le nombre de pièces non commandées (« Unvalidated Purchase Order ») et le nombre de pièces commandées et validées (« Validated Order »).
Suivre, via le workflow de validation, la date et la signature de chaque action validée (réception, préparation, envoi au traitement).
Générer des rapports d’état de production indiquant : le total des pièces en cours, le pourcentage de pièces validées, les écarts entre les numéros de série fournisseurs et les numéros internes, et le nombre de documents PDF associés à chaque article.
[INFORMATION MANQUANTE]
Enregistrer la production : volume des données
- **Données référentielles** : chaque pièce crée une **fiche article** et une ou plusieurs **lignes** de nomenclature (BOM) importées depuis SOLIDWORKS ou saisies manuellement. Le système conserve le flag « créé depuis interface » pour identifier les lignes générées automatiquement. Aucun chiffre global n’est fourni ; [INFORMATION MANQUANTE] sur le nombre total d’articles et de lignes stockés.
- **Documents journaliers** : le processus implique la réception d’environ **10 pièces par jour** (documents à contrôler, checklist, étiquettes automatiques). Si le flux passe à **100 pièces par jour**, le volume de documents augmente proportionnellement. Aucun comptage précis n’est indiqué pour les semaines, mois ou années ; [INFORMATION MANQUANTE] sur le nombre de documents par période.
- **Liens externes** : les documents volumineux (ex. 160 pages) sont référencés via un **lien SharePoint** plutôt que stockés directement, limitant ainsi la charge de stockage dans Business Central.
- **Étiquetage** : chaque pièce reçoit automatiquement une étiquette contenant le projet, le numéro de série et le code article, générant un enregistrement supplémentaire par pièce.
En résumé, le système doit gérer :
- 10 → 100 documents de réception par jour (check‑list, étiquettes)
- une fiche article et ses lignes de BOM pour chaque pièce
- des liens SharePoint pour les documents lourds
Toutes les quantités précises au niveau hebdomadaire, mensuel ou annuel restent non spécifiées dans les notes. [INFORMATION MANQUANTE]
9.6. Ecarts critiques et interfaces
Identifier les écarts critiques :
- **Import BOM Catia → fiche article** : aucune interface automatisée pour récupérer les listes de pièces exportées depuis Catia (HTML/Excel) vers la fiche article de BC. → [Écart critique].
- **Gestion documents PDF** : le système actuel ne permet pas d’attacher les plans, certificats ou rapports PDF aux actions ; la traçabilité repose sur des dossiers Windows séparés. → [Écart critique].
- **Lead time et dates besoin** : aucune saisie de délai d’approvisionnement dans le tableau des pièces ; les dates sont uniquement renseignées dans les actions, sans champ dédié dans le journal des achats. → [Écart critique].
- **Validation des actions** : la validation se fait manuellement avec signature ; aucun workflow validation BC (workflow validation) n’est configuré pour automatiser la validation des commandes et des actions. → [Écart critique].
- **Synchronisation statut pièces** : les statuts (gris = non commandé, jaune = commandé, vert = reçu) sont gérés dans l’outil actuel, mais aucune liaison avec le tableau de bord de production BC (ex. : tableau de bord, journal des achats). → [Écart critique].
- **Arborescence conception ↔ assemblage** : l’arborescence issue de Catia ne correspond pas toujours à la logique d’assemblage ; aucune règle de mapping n’est définie dans BC. → [Écart critique].
Identifier les interfaces :
- **Catia → export BOM (HTML/Excel)** : source des listes de pièces à intégrer dans la fiche article.
- **Dossiers Windows partagés** : stockage des documents PDF (plans, certificats) actuellement hors BC.
- **Tableaux Unvalidated Purchase Order / Validated Order** : doivent être mappés respectivement au journal des achats (journal des achats) et aux entrées de production (fiche article) dans BC.
- **Actions → dates besoin** : les dates saisies dans les actions du système actuel devront être transférées vers les champs « Date de besoin » de la fiche article et le champ « Lead time » (à créer) dans BC.
Ces écarts et interfaces doivent être initialisés dans la liste des écarts délivrée qui doit être finie à la fin de la phase d’Analyse.
Décrire la situation actuelle : les équipes conçoivent les pièces dans Catia, extraient les listes de pièces (HTML ou Excel) et les importent dans un système interne qui reproduit l’arborescence du modèle 3D. Chaque pièce possède un statut : gris (non commandée), jaune (commandée) ou vert (réceptionnée). Deux tableaux affichent les pièces : « Unvalidated Purchase Order » pour les pièces non commandées et « Validated Order » pour les pièces déjà validées. Les utilisateurs saisissent manuellement les dates de besoin, les numéros de commande et les actions dans la fiche de chaque article, puis valident les actions avec date et signature. La traçabilité repose sur ces validations. La documentation (plans, certificats PDF) n’est pas intégrée ; elle reste stockée dans des dossiers Windows séparés, ce qui impose une saisie manuelle supplémentaire.
Identifier les points critiques : absence d’intégration documentaire PDF dans le système, saisie manuelle fastidieuse, risque d’erreurs de traçabilité, dépendance à une arborescence 3D qui ne reflète pas toujours l’assemblage réel, besoin de vérifier l’unicité des numéros de pièces entre standards et projets, visibilité limitée sur les lead‑times et les dates d’approvisionnement.
Lister les attentes du client : automatiser la création et la mise à jour des fiches article, intégrer les documents PDF directement dans le système, synchroniser les statuts de production avec les commandes d’achat, disposer d’un tableau de bord personnalisable selon le rôle (gestionnaire d’activité, chef de projet), réduire la charge de saisie manuelle et améliorer la traçabilité des actions.
Formuler les hypothèses impactant le projet : le client continuera d’utiliser les listes de pièces exportées de Catia (HTML/Excel) comme source principale ; les catégories de pièces (standards, projets) resteront codifiées selon la logique actuelle (ALM, DES, B01, B02, …) ; les utilisateurs disposeront d’un accès aux dossiers Windows pour la documentation externe ; le système devra pouvoir reproduire l’arborescence existante tout en permettant des raccourcis personnalisés sur le tableau de bord. [INFORMATION MANQUANTE] [INFORMATION MANQUANTE]
Les hypothèses qui peuvent avoir un impact sur le projet doivent être indiquées.
10.2 Schéma des processus ERP : Terminer la production 6.0
10.3. Principales règles de gestion
Gérer la traçabilité des pièces : la **fiche article** reprend l’arborescence issue de Catia ; chaque nouvelle pièce se crée après recherche d’existence dans la base, puis on saisit le fichier 3D et on le partage dans les dossiers Windows.
Attribuer les actions : dans la **fiche article**, le volet *Actions* permet de renseigner la date de besoin, le numéro de commande (usineur, sous‑traitant) et les quantités. Le **workflow validation** consigne la date et la signature de la personne qui a validé chaque action, assurant un suivi complet.
Valider les commandes : le chef de projet utilise le **journal des achats** pour créer les ordres d’achat, réserver un numéro et, le cas échéant, générer le document papier. Le bouton *validation* du workflow attribue le numéro de commande à chaque article, déplace les lignes du tableau « à commander » vers le tableau « commandées », et indique que la pièce est « achetée ».
Regrouper les validations : lorsqu’une même pièce apparaît dans plusieurs sous‑ensembles, le **workflow validation** groupe les validations de commandes et d’actions, réduisant le temps de saisie tout en conservant la traçabilité de chaque montage.
Contrôler la réception : dès l’arrivée du paquet, l’opérateur d’atelier lance le **journal d’entrée** (incoming). Le responsable indique la réception physique, puis le **workflow validation** du contrôle qualité (niveau simplifié ou poussé) confirme que la pièce correspond aux exigences du projet.
Communiquer les exigences : le chef de projet inscrit dans les *Actions* les certificats ou contrôles spécifiques (ex. « certificat 3.1 demandé »).
Intégrer la documentation : lorsqu’un fournisseur fournit un PDF (plan, certificat), il faut l’attacher à la **fiche article** via le module de gestion documentaire ; sinon, les PDF restent stockés séparément dans les dossiers Windows.
Suivre les besoins et les livraisons : les tableaux de la **fiche article** affichent les besoins (« needed »), les livraisons, les pièces de rechange et les quantités commandées, permettant au chef de projet de vérifier l’état d’avancement.
[INFORMATION MANQUANTE]
10.4. Documents et statistiques
Imprimer le bon de commande papier depuis le **journal des achats** lorsqu’un chef de projet réserve un numéro et crée le document Word de commande ; imprimer la **check‑list d’incoming** et le **rapport de réception** que l’opérateur d’atelier complète lors de l’arrivée des pièces.
Afficher dans le **tableau de bord** les indicateurs suivants : nombre de pièces non commandées (tableau *Unvalidated Purchase Order*), nombre de pièces validées (tableau *Validated Order*), quantité commandée vs. quantité reçue, nombre de spares et statut de chaque article.
Enregistrer dans le **workflow validation** la date et la signature de chaque action validée (réception, préparation, envoi au traitement) pour assurer la traçabilité.
Mettre à jour la **fiche article** avec les numéros de rapport, les références de dessin et, le cas échéant, le lien SharePoint vers le PDF du plan ou du certificat (gestion documentaire hors ERP).
Générer les états : synthèse des commandes en cours, récapitulatif des pièces validées, tableau de suivi des numéros de série fournisseurs.
Ces documents imprimés et ces statistiques métier permettent de clôturer le processus « Terminer la production » en garantissant visibilité, conformité et traçabilité.
[INFORMATION MANQUANTE]
Indiquer le volume des fiches article : réception actuelle de 10 pièces par jour ; prévision de 100 pièces par jour → le nombre d’enregistrements référentiels augmente proportionnellement.
Indiquer le volume des documents : création d’un lien SharePoint vers un document de 160 pages ; chaque version de nomenclature génère un nouveau lien ; fréquence de création non précisée.
[INFORMATION MANQUANTE] – nombre de documents générés quotidiennement, hebdomadairement, mensuellement ou annuellement.
Indiquer le volume des lignes BOM importées depuis SOLIDWORKS : chaque import crée automatiquement les articles associés dans la fiche article ; les lignes manuelles restent inchangées.
Indiquer le volume des étiquettes : génération automatique d’étiquettes pour chaque pièce ; volume dépend du nombre de pièces reçues (10 / jour aujourd’hui, potentiel 100 / jour).
[INFORMATION MANQUANTE] – répartition temporelle précise des documents (journée, semaine, mois, année).
10.6. Ecarts critiques et interfaces
Identifier les écarts critiques :
- **Import BOM Catia → fiche article** : aucune interface automatisée pour extraire les listes de pièces (HTML/Excel) depuis Catia et les créer directement en fiche article ; le processus repose sur une saisie manuelle.
- **Gestion des délais d’approvisionnement** : le système actuel ne permet pas de saisir de lead‑time dans le journal des achats ; les dates de besoin sont uniquement renseignées dans les actions d’un article.
- **Attachement de documents PDF** : impossible d’associer plans, certificats ou rapports PDF aux actions d’une fiche article ; les pièces jointes restent stockées séparément dans des dossiers Windows.
- **Traçabilité des validations** : les signatures et dates de validation sont saisies manuellement dans les actions, sans workflow validation automatisé ni audit trail intégré.
- **Cohérence arborescence conception ↔ production** : la structure hiérarchique générée dans Catia ne correspond pas toujours à l’assemblage réel, entraînant des incohérences lors du suivi des sous‑ensembles dans BC.
Définir les interfaces :
- **Interface Catia ↔ BC** : créer un connecteur pour importer automatiquement le BOM (HTML/Excel) dans les fiches article, incluant les catégories (standard, projet) et la codification (ALM, DES, B01, B02…).
- **Interface BC ↔ système de fichiers** : développer un lien permettant d’attacher directement les PDF aux actions d’une fiche article, éliminant le stockage parallèle sur les partages Windows.
- **Interface BC ↔ module achats** : synchroniser les dates de besoin et les lead‑time avec le journal des achats et les ordres d’achat validés, afin d’alimenter les tableaux Unvalidated Purchase Order et Validated Order.
- **Interface BC ↔ workflow validation** : activer un workflow de validation des actions avec signature électronique, garantissant la traçabilité et le suivi des validations.
Ces écarts et interfaces seront consignés dans la liste des écarts à finaliser à la clôture de la phase d’analyse.
Ces écarts et interfaces doivent être initialisés dans la liste des écarts délivrée qui doit être finie à la fin de la phase d’Analyse.
Décrire la situation actuelle : les utilisateurs extraient depuis Catia (ou 4K) des listes de pièces au format HTML ou Excel, puis les importent dans un système interne où chaque pièce apparaît dans une **fiche article** (onglet « General Data »). Le panneau de gauche reproduit l’arborescence du modèle 3D, les statuts sont codés par couleur (gris = non commandé, jaune = commandé, vert = réceptionné). Deux tableaux affichent les pièces : « Unvalidated Purchase Order » (pièces non commandées) et « Validated Order » (pièces déjà commandées). Les utilisateurs renseignent dans les actions de la fiche article des dates de besoin, des numéros de commande et valident chaque action ; la validation consigne date et signature, constituant ainsi un **workflow validation**.
Points critiques :
- Absence d’attachement de documents PDF (plans, certificats) aux actions ; la documentation reste stockée manuellement dans des dossiers Windows.
- Saisie manuelle lourde des numéros de rapport et des dates, source de risques d’erreurs.
- L’arborescence du système suit la structure du modèle 3D, ce qui crée parfois des incohérences entre conception et assemblage final.
Attentes client : disposer d’un tableau de bord personnalisable selon le rôle (gestionnaire d’activité, chef de projet, production) avec recherche rapide (petite loupe) et raccourcis favoris, automatiser l’import des listes de pièces, intégrer les PDF directement dans la **fiche article**, et fluidifier le **workflow validation** pour garantir traçabilité et conformité.
Hypothèses impactant le projet :
- Le client adoptera les rôles BC pour configurer des tableaux de bord différenciés.
- Les listes de pièces seront importées via des fichiers Excel/HTML compatibles avec les tables BC.
- L’intégration des PDF nécessitera l’activation du stockage de documents dans Business Central (SharePoint ou Azure).
- Le processus de validation pourra être modélisé par un workflow BC standard, incluant dates de besoin et signatures électroniques.
[INFORMATION MANQUANTE]
Les hypothèses qui peuvent avoir un impact sur le projet doivent être indiquées.
11.2. Schéma des processus ERP : Rapports 7.0
Configurer le tableau de bord : l’utilisateur accède à un tableau de bord personnalisable selon son rôle (gestionnaire d’activité, chef de projet, responsable production). Il utilise la petite loupe pour rechercher des **rapports** (ex. : devis) et les ajouter aux favoris, créant ainsi des raccourcis visibles sur le tableau de bord.
Rechercher les pièces : via la loupe, l’utilisateur interroge la **fiche article** (onglet *General Data*) pour afficher les informations générales d’une pièce ou d’un assemblage. Dans la partie droite, il accède aux **actions** associées, où il peut saisir des dates de besoin, des numéros de commande et valider chaque action.
Valider les actions : le **workflow validation** permet à l’opérateur (ex. : Daniel) de cocher la case « validé », d’enregistrer la date et la signature de la personne qui a validé. Cette validation déplace les lignes du tableau « Unvalidated Purchase Order » vers le tableau « Validated Order », assurant la traçabilité des commandes.
Consigner la documentation : les rapports, plans et certificats PDF ne peuvent pas être intégrés directement dans les actions ; ils restent stockés dans les dossiers Windows et sont renseignés manuellement dans les champs correspondants.
Gérer les statuts : les pièces apparaissent en gris (non commandées), jaune (commandées) ou vert (réceptionnées) dans l’arborescence, offrant une visibilité instantanée du statut de chaque article.
[INFORMATION MANQUANTE]
11.3. Principales règles de gestion
Gérer les listes de pièces depuis **Catia** → extraire l’arborescence complète → importer dans la **fiche article** de Business Central.
Contrôler la création de nouvelles pièces → rechercher l’existence dans la base → si absent, créer la fiche article, associer le fichier 3D et placer le lien dans les dossiers partagés.
Attribuer la numérotation projet → le designer saisit le numéro de départ 0 dans la fiche article et le maintient cohérent avec l’assemblage final.
Planifier les besoins → dans la fiche article, remplir le champ **Date de besoin** et le **Numéro de commande** dans la section **Actions**.
Valider les actions → utiliser le **workflow validation** : chaque responsable signe, la date et la signature s’enregistrent, garantissant la traçabilité de la réception, de la préparation et de l’envoi au traitement.
Regrouper les validations → lorsqu’une même pièce apparaît dans plusieurs sous‑ensembles, cocher les cases correspondantes et valider en bloc, ce qui accélère le suivi.
Passer les commandes → le chef de projet ouvre le **journal des achats**, filtre par sous‑traitant, réserve le numéro de commande, saisit les quantités et clique **Valider** pour déplacer les lignes du tableau « à commander » vers le tableau « commandées ».
Générer les documents papier → copier‑coller les références d’articles depuis le journal des achats vers le modèle Word, puis imprimer la commande signée.
Intégrer la documentation → lorsqu’un PDF (plan, certificat, rapport) est fourni, l’attacher à la fiche article via le champ **Documents** (actuellement non utilisé, donc stocké manuellement dans Windows).
Réceptionner les pièces → l’opérateur d’atelier effectue l’**incoming** : enregistrement de la réception, puis lancement du **contrôle d’entrée** (qualité simplifiée ou poussée) via le workflow dédié.
Notifier le chef de projet → après l’**incoming**, le système envoie une notification indiquant que la pièce est reçue et, si le contrôle qualité est validé, qu’elle est disponible pour l’assemblage.
[INFORMATION MANQUANTE]
11.4. Documents et statistiques
Imprimer le bon de commande papier : le chef de projet génère manuellement un fichier Word contenant les références d’article, le sous‑traitant et les quantités, puis le signe et l’envoie au fournisseur.
Imprimer le rapport de réception : l’opérateur d’atelier complète une checklist papier à la réception des pièces, consigne le numéro de série fourni par le sous‑traitant et signe.
Imprimer les certificats ou rapports de mesure : lorsqu’un fournisseur fournit un rapport de mesure, il est imprimé et archivé physiquement car le système ne permet pas d’attacher les PDF.
Statistiques métiers attendues :
- Nombre de pièces « Unvalidated Purchase Order » affichées dans le tableau supérieur ;
- Nombre de pièces « Validated Order » affichées dans le tableau inférieur ;
- Total des pièces commandées, livrées et en stock de pièces de rechange (spares) extrait du tableau des numéros d’achat;
- Taux de validation des actions (date et signature de la personne ayant validé) pour chaque étape (réception, préparation, assemblage);
- Suivi de la traçabilité des pièces : correspondance entre le numéro de projet, le numéro de série fournisseur et le numéro de pièce dans la fiche article.
[INFORMATION MANQUANTE] – Objet BC exact à imprimer (ex. : « fiche article », « journal des achats », « workflow validation ») n’est pas mentionné dans les notes.
[INFORMATION MANQUANTE] – Format et périodicité des états statistiques (ex. : rapports Excel, Power BI) non précisés dans les notes.
Recenser les volumes de données référentielles : [INFORMATION MANQUANTE].
Recenser le nombre de documents entrants : les utilisateurs reçoivent aujourd’hui **10 pièces par jour** (documents d’entrée) et anticipent une hausse pouvant atteindre **100 pièces par jour**. Aucun chiffre n’est fourni pour les périodes hebdomadaires, mensuelles ou annuelles.
Recenser les objets BC concernés : les **fiche article** créées à partir de la **BOM** sont importées, les **lignes** de la BOM proviennent de SOLIDWORKS ou sont saisies manuellement, et chaque ligne porte un flag « créé depuis interface ». Ces lignes permettent de relier les documents (ex. lien SharePoint) aux projets et aux numéros de série.
Recenser les volumes de suivi : aucune donnée chiffrée n’est mentionnée concernant le nombre de projets, d’étiquettes ou de ressources planifiées dans le temps.
Recenser les besoins de suivi : le processus actuel repose sur une checklist manuelle pour chaque document entrant, sans métriques précises sur la charge de travail (heures ou opérations).
En l’absence d’informations supplémentaires, les volumes de données référentielles et les décomptes par semaine, mois ou année restent **[INFORMATION MANQUANTE]**.
11.6. Ecarts critiques et interfaces
Identifier les écarts critiques et les interfaces relevés lors des ateliers :
- **Tableau de bord personnalisable** : l’interface actuelle permet de créer des raccourcis et des bookmarks, mais aucune liaison directe avec les objets BC (ex. : *fiche article*, *journal des achats*) n’est définie. → [INFORMATION MANQUANTE] pour la synchronisation avec la *fiche article*.
- **Recherche de données** : la petite loupe recherche des menus et des listes d’articles, mais le moteur de recherche ne récupère pas les enregistrements BC (ex. : *fiche article*). → [INFORMATION MANQUANTE] sur l’indexation BC.
- **Gestion des nomenclatures** : les listes de pièces proviennent de Catia (HTML, Excel) et sont saisies manuellement dans le système actuel. Aucun import automatisé vers la *fiche article* ou le *journal des achats* n’est prévu. → Interface manquante entre Catia/Excel et BC.
- **Suivi des actions et validation** : les actions affichent des dates de besoin, numéros de commande et permettent la validation avec signature, mais il n’existe pas de *workflow validation* intégré à BC pour automatiser ces étapes. → Besoin d’un *workflow validation* dédié.
- **Traçabilité documentaire** : impossibilité d’attacher des PDF (plans, certificats) aux actions ; la documentation reste stockée dans des dossiers Windows séparés. → Interface manquante avec le gestionnaire de documents BC.
- **Lead‑time et dates d’approvisionnement** : le système actuel ne propose pas de champ dédié aux délais d’approvisionnement dans les articles ; les dates sont saisies uniquement dans les actions. → Absence de champ *Lead‑time* dans la *fiche article*.
- **Gestion des sous‑ensembles multiples** : les pièces apparaissent plusieurs fois dans l’arborescence sans consolidation automatique dans BC, ce qui complique les validations groupées. → Interface à définir entre l’arborescence Catia et la *fiche article* pour la consolidation.
Décrire la situation actuelle : les utilisateurs conçoivent les pièces sous Catia, extraient les listes de pièces au format HTML ou Excel, puis les importent dans le système interne. Chaque pièce possède une fiche article (General Data) où l’on saisit les informations générales et les actions (dates de besoin, numéros de commande). Le statut de chaque pièce s’affiche dans une arborescence : gris = non commandé, jaune = commandé, vert = reçu. Deux tableaux affichent les pièces : « Unvalidated Purchase Order » (pièces non commandées) et « Validated Order » (pièces commandées et réceptionnées). Les actions sont validées manuellement ; la validation consigne la date et la signature de l’utilisateur, assurant ainsi la traçabilité.
Identifier les points critiques :
- Absence de rattachement de documents PDF (plans, certificats) aux fiches article ou aux actions ; la documentation reste stockée dans des dossiers Windows séparés.
- Saisie manuelle intensive des données (dates, numéros de rapport), source d’erreurs et de perte de temps.
- Incohérence possible entre l’arborescence de conception (Catia) et l’arborescence du système, compliquant la gestion des sous‑ensembles et des pièces récurrentes.
- Aucun lead‑time ou délai d’approvisionnement intégré dans le système actuel.
Attentes client : [INFORMATION MANQUANTE]
Formuler les hypothèses pouvant impacter le projet :
- Supposer que Business Central pourra intégrer les PDF directement dans la fiche article ou les actions via le champ « Attachment ».
- Supposer que le workflow validation de BC pourra remplacer la validation manuelle actuelle et automatiser la traçabilité.
- Supposer que la migration des listes de pièces depuis Catia vers BC respectera la structure d’arborescence existante.
- Supposer que les catégories de pièces (standards, projets) seront mappées sur les groupes d’articles de BC sans perte de logique de codification.
[INFORMATION MANQUANTE]
Les hypothèses qui peuvent avoir un impact sur le projet doivent être indiquées.
12.2 Schéma des processus ERP : Historiques 8.0
Tracer chaque action sur la pièce : l’utilisateur ouvre la fiche de la pièce, saisit les besoins dans le champ « date de besoin », crée le numéro de commande dans le champ « numéro de commande », puis valide l’action. Enregistrer la date et la signature du valideur dans le champ « validation ».
Déplacer la pièce du tableau « Unvalidated Purchase Order » vers le tableau « Validated Order » dès que l’action est validée.
Consulter l’état de chaque pièce dans l’arborescence : gris = non commandée, jaune = commandée, vert = réceptionnée.
Mettre à jour le statut dans le tableau de bord dès qu’une pièce change d’état.
Consigner les documents associés (plans, rapports, certificats) en les joignant manuellement dans les dossiers Windows, car le système ne permet pas d’attacher des PDF directement aux actions.
Vérifier la cohérence entre la nomenclature issue de Catia et les pièces listées dans le système : si une pièce n’existe pas, rechercher dans la base de données, puis créer une nouvelle entrée.
Appliquer la même arborescence que le modèle 3D pour faciliter le suivi des sous‑ensembles et des pièces récurrentes.
Regrouper les validations de commandes et d’actions pour les pièces présentes dans plusieurs sous‑ensembles afin de gagner du temps.
[INFORMATION MANQUANTE]
[INFORMATION MANQUANTE]
[INFORMATION MANQUANTE]
12.3. Principales règles de gestion
Gérer les listes de pièces depuis Catia : extraire l’arborescence et le récapitulatif, puis créer chaque **fiche article** dans BC après vérification de l’existence dans la base.
Attribuer la numérotation : le designer d’un projet initialise la séquence à zéro dans la **fiche article** et saisit les dates de besoin dans le champ « actions » du **General Data**.
Valider les actions : chaque intervenant utilise le **workflow validation** pour cocher l’action, enregistrer la date et signer. La traçabilité s’affiche dans la **fiche article** et permet de suivre réception, préparation, envoi au traitement.
Documenter les pièces : les plans PDF, rapports et certificats ne s’intègrent pas dans les actions ; ils restent dans les dossiers Windows partagés.
Regrouper les validations : lorsqu’une même pièce apparaît dans plusieurs sous‑ensembles, le **workflow validation** permet de valider les commandes et actions groupées, gagnant du temps et assurant la traçabilité d’une pièce unique.
Créer les ordres d’achat : le chef de projet ouvre le **journal des achats**, recherche par sous‑traitant, réserve le numéro de commande, puis clique **validation** pour affecter la commande à chaque **fiche article**. La validation déplace les lignes du tableau supérieur vers le tableau inférieur, indiquant l’état « acheté ».
Générer les documents papier : après validation, le chef de projet copie manuellement les références d’articles depuis BC vers un fichier Word pour la commande papier.
Utiliser Excel pour les offres : les listes de pièces ne sont pas importées dans BC ; le chef de projet travaille sur des fichiers Excel pour les appels d’offres.
Intégrer les certificats fournisseurs : lorsqu’un fournisseur fournit un PDF de tolérance ou de contrôle qualité, le chef de projet indique « certificat 3.1 demandé » dans les **actions** de la **fiche article**.
Contrôler l’entrée : à la réception, l’opérateur d’atelier lance le processus d’**incoming** (journal d’entrée), vérifie la conformité, puis informe le chef de projet. Deux niveaux de contrôle qualité – simplifié ou poussé – s’appliquent selon les exigences du projet.
12.4. Documents et statistiques
Imprimer le document de commande papier (créé par le chef de projet) : formulaire contenant le numéro d’article, le sous‑traitant, les références projet et, le cas échéant, le numéro de rapport à recopier manuellement.
Imprimer le bon de validation (papier) : fiche où l’opérateur saisit la date et la signature de la personne qui a validé chaque action (réception, préparation, envoi au traitement).
État métier attendu : tableau **Unvalidated Purchase Order** affichant les pièces non commandées, tableau **Validated Order** affichant les pièces déjà commandées, statut vert indiquant les pièces réceptionnées avec toutes les actions validées.
Statistiques attendues :
- Nombre total de pièces non commandées vs nombre de pièces validées.
- Nombre de pièces réceptionnées (statut vert).
- Nombre de spares et quantité commandée par sous‑traitant.
- Suivi des numéros de rapport, numéros de projet et numéros de série fournisseur associés aux pièces.
- Taux de validation des actions (date + signature) par période.
[INFORMATION MANQUANTE]
Décrire le volume des données référentielles : [INFORMATION MANQUANTE].
Indiquer le nombre de documents par période : le processus *incoming* crée actuellement environ **10 pièces** par jour dans le **journal des achats** (check‑list associée). Le suivi s’effectue via la **fiche article** et le **workflow validation** qui enregistrent chaque pièce reçue. Si le flux monte à **100 pièces** par jour, le système devra gérer ce volume supplémentaire. Aucun autre intervalle (semaine, mois, année) n’est explicitement mentionné dans les notes.
12.6. Ecarts critiques et interfaces
Identifier les écarts critiques et les interfaces :
- **Tableau de bord personnalisable** : l’interface actuelle permet de créer des raccourcis et des bookmarks favoris, mais aucun objet BC tel que le *tableau de bord* standard ne gère la personnalisation par rôle (gestionnaire d’activité, chef de projet, production). → besoin d’une interface de configuration du *tableau de bord* par rôle.
- **Recherche et navigation** : la petite loupe permet de rechercher des menus, des devis ou des articles, mais le système ne propose pas de recherche intégrée sur la *fiche article* ni sur le *journal des achats*. → interface de recherche globale à implémenter.
- **Importation de nomenclatures** : les listes de pièces proviennent de Catia sous forme de fichiers HTML ou Excel. Aucun mécanisme d’import automatique vers la *fiche article* ou le *journal des achats* n’est décrit. → interface d’import BOM (HTML/Excel) vers la *fiche article*.
- **Gestion des délais d’approvisionnement** : le système actuel ne permet pas de saisir de lead‑time ou de date de besoin directement dans le *journal des achats* ; les dates sont uniquement renseignées dans les actions de la *fiche article*. → champ « lead time » manquant dans le *journal des achats*.
- **Traçabilité des actions** : les actions (commande, réception, traitement) sont validées manuellement avec date et signature, mais il n’existe pas de *workflow validation* intégré à la *fiche article* pour automatiser cette traçabilité. → besoin d’un *workflow validation* lié aux actions.
- **Gestion documentaire** : impossible d’attacher des PDF (plans, certificats, rapports) aux actions de la *fiche article* ; la documentation est stockée séparément dans des dossiers Windows. → interface de gestion documentaire à intégrer à la *fiche article*.
- **Couleurs d’état des pièces** : le système utilise un code couleur (gris, jaune, vert) pour indiquer le statut des pièces, fonctionnalité non répliquée dans les objets BC standards. → besoin d’un champ d’état ou d’une visualisation couleur dans la *fiche article* ou le *journal des achats*.
- **Arborescence et duplication de pièces** : l’arborescence reproduit la structure Catia, créant des doublons de pièces dans plusieurs sous‑ensembles, sans mécanisme de regroupement automatique dans BC. → interface de synchronisation de l’arborescence avec la *fiche article* pour éviter les doublons.
Initialiser la liste d’écarts dès le lancement de la phase d’analyse du processus de production décrit lors de l’atelier ERP – Production.
Collecter les écarts relevés pendant la revue du flux : extraction des listes de pièces depuis le logiciel 3D (Catia), comparaison avec les nomenclatures existantes, suivi des statuts (gris = non commandé, jaune = commandé, vert = réceptionné) et validation des actions dans le tableau « Unvalidated Purchase Order » puis le tableau « Validated Order ».
Enregistrer chaque différence (ex. absence de pièce dans le référentiel, codification non conforme, impossibilité d’attacher les PDF de plans ou certificats) dans la liste d’écarts.
Finaliser la liste d’écarts à la clôture de l’analyse, après validation des actions et traçabilité des signatures.
URL de stockage de la liste d’écarts : [INFORMATION MANQUANTE].
Indiquer l’URL où la liste des écarts sera stockée (SharePoint / Teams / DevOps / Autre).
Contenu par Sections
Contenu organisé par sections avec édition individuelle.
3.1. Contexte et Hypothèses
3.3. Principales règles de gestion
3.4. Documents et statistiques
3.5. Volume des données
3.6. Ecarts critiques et interfaces
4.1. Contexte et Hypothèses
4.3. Principales règles de gestion
4.4. Documents et statistiques
4.5. Volume des données
4.6. Ecarts critiques et interfaces
5.1. Contexte et Hypothèses
5.3. Principales règles de gestion
5.4. Documents et statistiques
5.5. Volume des données
5.6. Ecarts critiques et interfaces
6.1. Contexte et Hypothèses
6.3. Principales règles de gestion
6.4. Documents et statistiques
6.5. Volume des données
6.6. Ecarts critiques et interfaces
7.1. Contexte et Hypothèses
7.3. Principales règles de gestion
7.4. Documents et statistiques
7.5. Volume des données
7.6. Ecarts critiques et interfaces
8.1. Contexte et Hypothèses
8.3. Principales règles de gestion
8.4. Documents et statistiques
8.5. Volume des données
8.6. Ecarts critiques et interfaces
9.1. Contexte et Hypothèses
9.3. Principales règles de gestion
9.4. Documents et statistiques
9.5. Volume des données
9.6. Ecarts critiques et interfaces
10.1. Contexte et Hypothèses
10.3. Principales règles de gestion
10.4. Documents et statistiques
10.5. Volume des données
10.6. Ecarts critiques et interfaces
11.1. Contexte et Hypothèses
11.2. Schéma des processus ERP : Rapports 7.0
11.3. Principales règles de gestion
11.4. Documents et statistiques
11.5. Volume des données
11.6. Ecarts critiques et interfaces
12.1. Contexte et Hypothèses
12.2. Schéma des processus ERP : Historiques 8.0
12.3. Principales règles de gestion
12.4. Documents et statistiques
12.5. Volume des données
12.6. Ecarts critiques et interfaces
13.1. Liste d’écarts
Édition Avancée
Modifiez le document complet avec des outils avancés.